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Abstract 

We describe a policy language and implement its associated proof checking system. In our system, agents can distribute 
data along with usage policies in a decentralized architecture. Our language supports the specification of conditions and 
obligations, and also the possibility to refine policies. In our framework, the compliance with usage policies is not actively 
enforced. However, agents are accountable for their actions, and may be audited by an authority requiring justifications. 
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I — I \ 1 Introduction 

m ■ 

^ ■ In many situations, there is a need to share data between potentially untrusted parties while ensuring the data is used 
,—1 ' according to given policies. This problem is addressed by two main research streams: on one hand, there is a large body of 
0^ ' literature on access (and usage) control (8][l6|[n]|4l, on the other hand we find digital rights management llSi ilSll. While the 
former assumes a trusted access control service restricting data access, the latter assume trusted devices in charge of content 
rendering. Both settings need the trusted components to be available at the moment the request happens, to regulate the data 
access. 
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• However, there are scenarios (like the protection of private data) in which both access control and digital rights manage- 
ment fail, either because the necessary trusted components are not available or because they are controlled by agents we do 
not want to trust. For instance, P3P 1171 and E-P3P (and also EPAL) are languages that allow one to specify policies for 
privacy protection; however, the user can only hope that the private data host follows them. 

In this paper, the process of regulating the data access is not assumed to be always performed by the same entity at the 
same moment in which the access is requested. More specifically, we relax this in mainly two ways: 



• Firstly, at the moment that the data is requested, we assume that access is always granted, and only later it is determined 
whether the requestor had permission to access the data. This is the process of auditing. To achieve this, we need all 
the relevant decision information to be kept until audit time (e.g. keeping secure logs). 

• Secondly, the entity that is performing the auditing does not need to be fixed, and can thus be dynamically chosen. 
This is useful since, for example, some authorities are more appropiate to audit specific agents than others. The actual 
authority does not even need to be one single entity, and can be for example composed of regular agents. 

We present a flexible system which allows to express, deploy and reason about policies controlling the usage of data. In 
our target setting agents can distribute data along with usage policies within a highly decentralized architecture, in which the 
enforcement of policies is difficult (if not impossible). Therefore, we use instead an auditing system with best-effort checking 
by an authority which is able to observe (some) actions. We introduce a notion of agent accountability and express the proof 
obligation of an agent being audited. The system allows to reason about policies and user accountability. Our framework is 
depicted in Figure^ 

* This is an extended version of tlie article to appear in the Conference Proceedings of the 6th IEEE International Workshop on Policies for Distributed 
Systems and Networks (POLICY 2005) 
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B and C's environment 




Figure 1. Our framework 



We make no assumptions on the existence of trusted components regulating access (although we do require a trusted 
environment to certify environmental conditions, and to securely log events). In fact, agents are not forced to follow the 
policies, but may be audited by authorities which ask for justifications. We make no particular assumptions about authorities; 
they may comprise, for instance, of groups of regular agents. The more an authority can observe, the more accurate the 
auditing process is, thus providing more confidence over the agent's behaviour. To characterize compliant agent behaviour, 
as perceived by an authority, we define accountability tests, which are carried out during auditing by the authority. 

Of course, our approach does not allow a strict policy enforcement: agents can easily "misbehave" (i.e. treat data in a 
way that is not allowed by the policy), at risk of being traced. It is our belief that in many emerging scenarios active policy 
enforcement is infeasible. 

This paper builds on the preliminary work reported in |6|. In particular, we provide several extensions, the most notable 
of which are: 

• We include the ability to specify conditions and obligations within the policies. 

• Policies may now contain variables and quantifiers. This allows us to define a fundamental rule that gives the ability to 
refine policies. Agents can create (by refinement) new policies from existing ones, before passing them to other agents. 
In contrast, in |6j the only policies allowed are those that are explicitly stated by the data owner. 

• We precisely describe our system by introducing three functions, namely the observability, conclusion derivation and 
proof obligation functions. Moreover, we provide a customizable action set to account for particular, user-defined 
scenarios. 

• We define agent accountability tests, and present a (terminating) procedure for recursive auditing. 

• Finally, we provide a formalization of our proof system in the proof checker Twelf ll3l . which allows us to model 
proofs provided by agents, and the subsequent checking by the authority (Our formalization covers the lower part of 
Figured) 
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2 A System of Policies and Actions 



Our setup consists of a group of agents executing different actions. The permission to execute an action is expressed by a 
policy constructed using a special logic, introduced below. In this section we introduce some necessary components for our 
system. 

2.1 The basics 

Agents are modelled by a set Q ranged over by a, b and c (referred to as Alice, Bob, and Charlie). We also have a set of 
agent variables Va and use A, B,C to range over both agents and agent variables. Similarly we have a set T> of data objects, 
ranged over by d, and a set of data variables Vd- We use D to range over data objects and data variables and x, y, z to range 
over (data and agent) variables. 

Basic permissions and/acfi are expressed by atomic predicates in a set C, ranged over by -p. Examples are read(a, d), 
which expresses that agent a has permission to read data d and partner(a, 6) indicating (the fact) that agent a and h are 
partners. In general, predicates can relate any number of data objects and agents. 

The actions that agents execute are modelled using a set of actions ACT, ranged over by act. We assume that two types of 
actions are always present in this set: Communication (of policies) COmm(a ^ 6, 0) and data creation creates(a, d). (Here 
a, h are agents and is a ground policy formula, as introduced in the next subsection). Our system supports the addition of 
user-defined actions. 

2.2 The Policy Language 

Policies are used to express permissions that agents have, such as the permission to read a specific piece of data. Some 
requirements may guard a permission. These requirements can be conditions, as in 'Alice may read the data if she is a partner 
of Bob', or obligations, as in Alice may read the data if she pays Bob 10$'. Besides this, a policy may express or relate 
several different permissions. To provide maximum flexibility for writing policies, we now introduce the following policy 
language. 

Definition 1 The set of policies $, ranged over by cf) and ip, is defined by the following grammar: 

4> ■■■■= p(si,...,s„) 

I A owns D I A says 4>to B 

I A 1 1 ^ 1 e ^ 

s A\D 
^ ::= \act \lact 

First, a policy formula can be a simple predicate p{si, s„), where s^'s can be either an agent, an agent variable, a data 
object or a data object variable. Second, we have the A owns D formula, which indicates that A is the owner of data object D. 
As we define below, an data owner is allowed to create usage policies related to that data. A says (p to B expresses that 
agent A is allowed to give policy (p to agent B. The 'says' policy contains a target agent to which the statement is said 
(different from e.g. E1[D)- This allows us to provide a precise way of communicating policies to certain agents. However, 
the policy A says (p to B carries a different meaning for source agent A than target agent B: While for agent A it represents 
the permission to send to B, for B it represents the possibility to use policy (p and delegate the responsibility to A. 

The logic constructions and, implication and universal quantification have their usual meaning. We actually have two 
different instances of the implication. The first, 4>' (f>, has a policy 0' as a condition, stating that the agent first needs 
to establish this permission or fact before gaining the permission described in (p. The second, ^ (/), is used to express 
obligations. The requirement ^ contains an action that the agent has to perform when the permission granted by (p is used. 
The annotations ! and ? indicate whether the agent needs to do this action every time it uses (p or only once. This will be 
discussed in Section l331 We write (p[D] to indicate that the set D is the data set of(p, i.e. all data objects and data variables 
occurring in (p. For instance, we have read (6, 

Example 1 The (atomic) policy that allows Bob to read the data d is read(&, d). 
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1. The policy that allows Bob to read every data object owned by Alice is ^x.{a OWns x read (5, x)). 

2. Let age21(x) denote that agent x is at least 21 years old, and alc(y) denote that beverage y is alcoholic. A policy 
allowing people over 21 to drink alcoholic beverages is Vx, y.{age 2l(x) A alc(y)) — > drink(.T, y). 

3. If we require a payment of 1Q% on the previous permission, the policy becomes yx.{\paid{x, 10$) Vy. (age 21 (a;) A 
a\c{y)) dnnk{x,y)). 

2.3 Actions and permissions 

To distinguish different instances of an action executed in the system, we label each instance using a unique identifier id, 
as in createSid(a, d). This formally gives a set AC = N ^ ACT of 'executed actions' or 'action instantiations'. However, 
when possible, we simply talk about (labeled) actions in AC. 

Three properties of actions that play a role in our policy system are described by the following functions: 

• The observability function: obs : AC P{Q) describes which agents can observe which actions. 

• The proof obligation function: pa : {AC x Q) ^ $ U {_L} describes which policy an agent needs to justify the 
execution of an action. Here ± indicates that no policy is needed. 

• The conclusion derivation function: concl : {ACT x Q) ^ ^ U { -L}, describes what pohcy can an agent deduce after 
observing an action. Here _L indicates that no policy can be deduced. 

While the observability and proof obligation functions depend on executed actions (i.e. with identifiers), the conclusion 
derivation function is purely syntactical. 

For our default actions creates(a, d) and COmm(a =^ b, (f>) we have: 



o6s(creates(a, d)) 


= a 


(1) 


obs{comm{a b, 0)) 


= {«,&} 


(2) 


po(creates(a, d),a) 


= L 


(3) 


po(comm(a b, 0), c) 


= L {a^c) 


(4) 


po(comm(a => b, 0), a) 


= a says to 6 


(5) 


concl {creates{a, d),a) 


= a owns d 


(6) 


cond(comm(a ^,0), h) 


= a says (j)tob 


(7) 


cond(creates(a, d), 6) 


= ± {b^a) 


(8) 


cond(comm(a 6, 0), c) 


= ± {c^b) 


(9) 



A creation action by a is observed by a Q, while a communication between a and b is observed by both a and b 0- In 
other settings, there may also be other agents that observe these actions, e.g. a router standing in between a and b. Agents 
do not need a policy for creating data (|3jl or receiving a transmission @. However, sending a transmission does require a 
permission Q. If agent Alice creates a piece of data she becomes the owner of this data (|6|i; any other agent can not deduce 
the ownership (|8}. If an agent receives a communication then the agent can conclude the corresponding says statement 0. 
However, any other agent can not deduce any conclusion (|5Jl. 

Remark 1 Our communication COmm{a 6, 0) models a point-to-point communication. We can easily model broadcast- 
ing, by introducing an action bcast(a, (f>), and setting: 

obs{hcast{a, cj))) 

po(bcast(a, (j)),x) 

cond (bcast(a, </)), a;) 

Where tp ~ ^y.a says (j) to y. 

Here, every agent can observe an action bcast(a, (p) and conclude that a has broadcasted <j) i.e. said (j) to everybody. Only 
a needs to justify this action. 



= g 

^ r ■0 (x = a} 
1 _L otherwise 

= V 
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2.4 The Proof System 



In the previous section we introduced the actions that agents can execute and the permissions that agents need to justify 
these actions, in form of policies. This section describes how agents perform this justification, i.e. how agents can build 
policies from (simpler) ones. The possibilities for constructing policies are given in the form of a derivation system or proof 
system for our policy language. 

Each rule includes, besides the premises and conclusion, an agent a, called the context of the proof, indicating which 
agent is doing the reasoning. Our derivation system DER contains the standard predicate logic rules for introduction and 
elimination of conjunction, implication and universal quantification, together with the following rules: 

b says to a 

SAY 7 a 

(f) ^ a says (/) to 6 

REFIME —. a 

a says ip\.ob 

act concl{act, a) ^1- 



□BS_ACT 



DERJ>OL 



concl{act, a) 

a owns di ... a owns d„ 

(f>[{di, . . .,dn}] 



Rule (SAY) models delegation of responsibility. If agent b says to a then a can assume to hold. (It is &'s responsibility 
to show that it had permission to give cf) to a, see Section l33l on accountability.) Although agent a may use cj) without further 
requirement, it does not mean that the agent must always do this. If Bob wants to do a specific sensitive action, he may 
only want to use communications that he 'trusts' in building his policy. For example. Bob would only trust and thus use a 
policy 'fire Charlie' if it is provided by his boss. If it is provided to him by coworker Alice, Bob will not use the policy, even 
though the responsibility of this policy would rest with Alice. In this setting, the problem of establishing and managing trust 
is orthogonal to the problem of obtaining policies: One could introduce a trust management system to assign a 'level of trust 
in a proof, and require that different levels of trust are established for different actions (see Section 6). 

In our logic, Alice can refine her own policies, e.g. by adding extra conditions and obligations using the standard proposi- 
tional rules. In addition, rule (REFINE) enables Alice to refine the poUcies she provides to other agents: if Alice is allowed 
to send some policy <f> then she can also send any refinement of 0. This notion of refinement isn't easily captured in natural 
deduction. The current notation is too general; without further restrictions it seems that a can derive (j) ip for any (syntac- 
tically unrelated) cj), provided she can assume Thus, we need to restrict the abiUty to use assumptions in the subproof of 
<j> ^ tp. In the formalization of our model, a double context sequent calculus, we can express this (see AppendixlAi. 

Rule (OBS_ACT) links an action with its conclusion, given by the concl function. (OBS_ACT) applies when there is some 
conclusion (i.e. concl{act, a) j^lS); e.g., from observing action COmm(a ^ b,(f))b derives a says to b. 

As we already mentioned, we design the logic in such a way that the owner of some data d decides who is allowed to do 
which actions on d. In other words, an owner of some data d is allowed to derive usage policies for d, targeted to any other 
agent. This is achieved by rule (DER_POL), which allows the creation of any usage policy for data which the agent owns. 
Non-owners can refine existing policies (e.g., policies they received), but cannot create new policies from scratch. 

A derivation with these rules made by an agent is a proof. 

Definition 2 A proof 7-" of (p from agent a is a finite derivation tree such that: (1) each rule ofV has a as subject; (2) each 
rule ofV belongs to DER, (3) the root ofV is 4>, and (4) each initial assumption is either an action, an obligation or a basic 
predicate. 

We call conditions cond{V) of V the initial assumptions that are basic predicates, and actions act{'P) the initial as- 
sumptions which are observed unguarded actions (from rule ( OBS-ACT) ). Finally, the multiset of initial assumptions that are 
guarded (by ? and !) actions are called the obligations oblig{V) ofV. 

We now illustrate the usage of rules (REFINE) and (DER_POL) in the following example. 
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[print(&, d)] 
[re\{d,x)] 

P"<^t{b,d) ^ creates(a, d) 

re\{d, x) ^ pr\nt{b, d) " cond(creates(a, d), a)) = a owns d 



Va-. rel((i, a;) print(6, d) " a owns d 

*^ print(6, d) \/x. re\{d, x) ^ print(6, d) " derjol ^ ^^^^ print(fe, d) to b 

a says Vz. re\{d, x) print(6, d) to b 



Table 1 . Proof for Example|^ 

Example 2 (Policy Refinement) Suppose we have a predicate rel {d, d), expressing whether two data objects are related: 
For instance, d can be a review of a new product and d the press release announcing this product. Alice creates d and wants 
to give a policy \/x. re\{d, x) — » print(6, d) to Bob giving Bob permission to print the document as soon as a related object 
exists: Alice can build the policy allowing her to give this policy to Bob as shown in Table^\ 

3 The Model 

We now introduce a model for our system, combining the different components of the previous sections. In our system, 
agents can execute and log actions. In addition to agents, an authority is also present. This authority may audit agents 
requiring justification for (some of) the agents actions. 

3.1 Logging actions 

Whenever an agent executes an action, it can also choose to log this action. Logged actions constitute evidences that can 
be used to demonstrate that an agent was allowed to perform a particular action. They are used during accountability auditing, 
in Section lSJl 

Definitions A logged action is a triple lac = (act, conds, obligs) consisting of an action act G AC, a set of atomic 
predicates conds (the 'conditions'), and a set of labelled annotated actions obligs C {\, 7} AC (the 'obligations'). The set 
of logged actions is denoted as LAC. 

When logging an action, an agent can include supporting conditions which the environment certifies to be valid at the 
moment of execution of the action. This is recorded in the set of predicates conds. We do not model the environment 
explicitly but instead assume that the agent obtains a secure "package" of signed facts from the environment, represented in 
conds. As an example, one can think of the driver's license of Alice being checked to certify that she is over 21. 

An agent can also include obligations in obligs in a logged action, which refers to other actions the agent did or promises 
to do. We abstract away from the details of expressing promises, and instead assume we have a way to check if actions have 
expired. For example, the agent may promise to pay within a day. Then a payment action needs to be done (and logged) 
within a day of logging this obligation. (Also see Section l3Jl ) 

Example 3 We continue with Example^S. Suppose that we introduce an action drunk(x, y) and a corresponding atomic 
predicate drink(a;,y), with cond(drunk(a;, y), x) =-L and po(drunk(x, y), x) = drink(x,y). We also introduce an action 
paid(a:;, y), with corresponding atomic predicate pay(a;, y), with cond(paid(a;, y), x) — po(paid(a;, y),x) 
A logged action lac^^y for payment is done first by a: 

lacp,y = (paido(a,lO$),0,0) 

Then, another logged action lacdrunkfor the action drunki (a, beer) is recorded: 

^acdrunk = (drunki (a, 6eer), 

{age21(a), alc(6eer)}, 
{!paido(a,10$)}) 
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The log of an agent a is a finite sequence of logged actions. Note that it does not need to be a who performed the actions, 
but of course a has to observe an action to be able to log it. We say that agent a logs action act when {act, conds, ohligs) is 
appended to the log of a, where conds is some set of conditions and ohligs is some set of obUgations. 

We assume the following consistency properties of logging: 

• An agent logs any action at most once, thus within an agent's log the logged actions are uniquely identified by the label 
(id) of the action. 

• An agent can include the same obligation \actid at most once within the obligations of logged actions in its log. (an 
lactid action, in contrast, may occur multiple time). 

• An agent cannot log an expired action. 

Notice that consistency of the log does not have to be checked at time of logging, it is sufficient to check it at time of 
auditing. 

3.2 The system model and state 

We are ready to introduce our system model. 
Definition 4 A system is a 6-tuple: 

{Q, ACT, obs, concl,po) 

where Q is a set of agents, $ is the policy language, ACT is a set of actions, and obs, concl and po are, respectively, the 
observability, conclusion and proof obligation functions. 

A state S is the collection of logs of the different agents, i.e. a mapping from agents to logs. An agent who observes an 
action may choose to log this action. Thus by executing action act the system can make a transition from a state S to state 

S', denoted S S' where S' equals S except that the action act may have have been logged by any agent a that can observe 
the action, a G ohs{act). An execution of the system consists of a sequence of transitions Sq Si "'^ ... Sn, starting 
with some initial state iSq. The execution trace for this execution is acti act2... act^. Actions logged by an agent can be also 
seen as a trace of actions, by projecting only the actions of each logged action. We denote that trace as S{a). Let ^ denote 
the subtrace relation [tri ^ tr2 if each action of tri is included in tr2, and each time an action acti appears before act2 in 
tri, the acti also appears before act2 in tr2). We have S{a) ^ tr. 

Auditing Authority Agents may be audited by some authority, at some state S. Intuitively, when some agent is about to be 
audited, an auditing authority is formed. This authority will audit the agent to find whether she is accountable for her actions. 
Let tr be the sequence of actions executed from some initial state to S, The evidence trace, denoted £, contains all the actions 
that might be audited. Initially, £ embeds S{a). However, £ may also contain actions not in S{a): They may be provided, 
for example, by some observing agents. However, we assume that given S{a) and other observed actions S, the authority 
can order properly the actions of S{a) and S into £, s.t. £ :< tr. Thus, in general £" is a trace satisfying S{a) < £ ^tr. 

3.3 Accountability 

We now introduce notions of agent accountability, determined by some authority in possession of evidences. These 
definitions allow an authority to audit agents, to establish whether the agent was allowed to do the actions he did. In previous 
work |j6J, we defined several notions of agent and data accountability, but without checking for obligations nor conditions. 
We did not have logs of agents either We now define accountability for logged actions, which we then extend to agent logs. 

We first introduce justification proofs for logged actions. Intuitively, a justification proof is a proof of the policy required 
for the action (as given by function po), using only conditions and obligations that have been logged. 

Definition 5 A proof V of (j) from a is a justification (proof) of logged action {act, conds, ohligs) if: 

• po{act, a) = 
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• The obligation in the proof are included in obligs; 'ohlig{V) C obligs'. (Here multiple lact in ohlig{V) may be 
assigned to the same lacUd but each occurrence of lact must have its own lactic in obligs.) ' 

• Each condition in the proof is in conds; cond{'P) C conds. 
The set of all justifications is denoted by J . 

In general, there may be different justifications for an action. The justifications provided by the agent are modeled by a 
function Pr : x LAC J \J {-L}. Here Pr(a, (act, conds, obligs)) is either a valid justification of {act, cojids, obligs), 
or it is ±, indicating that the agent did not provide a justification. 

Definition 6 (Logged Action Accountability) Agent a correctly accounts for logged action logact = {act, conds, obligs) 
(in state S), denoted LAA{a, logact), if: 

• if po{act, a) ^ _L then Pr(a, logact) ^ ±, i.e. if needed a justification is provided 

• if o £ obligs has expired then o £ S{a), i.e. each obligation that has expired has been (executed and) logged. 

• For each act e act{¥r{a, logact)), a provides an id s.t. actid occurs in tr and a G obs{actid)^ 

This definition introduces accountability for a single (logged) action. We now define accountability for any action and for all 
audited actions. 

Definition 7 (Action Accountability) We say that agent a correctly accounts for (labeled) action act, denoted AA{a, act), 
if 

• a has logged act as logact and LAA{a, logact) or 

• a has not logged act and LAA{a, {act, 0, 0)) 

We say agent a passes audit £, written ACC{a, £), if either £ is the empty trace, or £ ~ £' .act with: 

• AA{a, act) 

• ACC{a, £"), with £" the correct ordered merge of £' and newacts, all the new actions (i.e. not already in £') given 
by the proofs in AA{a, act). 

The second case for action accountability explains why it can be in the interest of an agent to log its actions. As conditions 
may have changed, the agent can only rely on conditions if they have been logged at the time the action was executed. For 
example, if some action had a condition 'only execute between 4 p.m. and 4:30 p.m. on 12/10/2004', then that condition 
would only hold temporarily; If an agent executed the action and did not log it, during a later audit the agent could not provide 
a valid proof. The same holds for obligations: Only obligations logged with the action can be used in a proof of the action. 

Claim 1 Let a be an agent and £ an evidence trace. Then, checking ACC'{a, £) terminates. 

Proof. Let \tr\ = n, for some n > 0. Suppose \£\ = m < n. We show that each execution of ACC{a, £) decreases I, with 
I = n initially. After every execution of ACC{a, £) as in Definition^ at most I — m evidences (the newacts) are added to 
£". Thus, \£"\ = \£'\ + {I - m) = m - I + {I - m) ^ I - 1. Hence, ACC{a, £) terminates. 

Honest Strategy A strategy for an honest agent a to always be accountable is as follows. Before executing some action 
act, a checks whether po{act, a) is derivable. If any obligation needs to be fulfilled, then the agent performs and then logs 
it. If any condition or obligation needs to be fulfilled, then the action act is also logged. Then, it follows from the definitions 
that: 

Remark 2 (Accountability of honest agents) If agent a follows the honest strategy, then for any system execution and any 
auditing authority with evidence set £, we have that ACC{a, £) holds. 

The proof follows immediately from Definitions |6]andQ 

'interpreting as sets for lact and as multisets for lact. 
^We assume the authority can verify this. 
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Recursive auditing We have, up to now, defined accountability of one particular agent in isolation. However, we may be 
interested in cross-verifying the actions of agents. We sketch an algorithm for recursive auditing of agents, which can be 
used by a potential auditing authority. The algorithm inputs Sq, a set of suspected agents, and Eq, an initial evidence trace. 
Given ACC{a, £), we write E{ACC{a, £)) to denote the set of new actions appearing in the given proofs (the newacts in 
Definition^, and A{ACC{a, £)) the corresponding set of agents appearing in these actions for which the proof obligation 
is not bottom, i.e. po{-, •) 

Algorithm 1 (Recursive Auditing) Inputs: Sq and £q. Outputs: true if audited agents are accountable, false otherwise. 

1. S:=So; 

2. 8 ■. = £o; 

3. while 5 / do 

4. letaGS; 

5. \tACC{a,£)ihm 

6. S:={S\{a})VjA{ACC{a,£)) 

7. £ ■. = £VjE{ACC{a,£)) 

8. else 

9. return false 

10. end 

11. return true 

Claim 2 Algorithm^terminates. 
Proof. Similar to the proof of Claim[3 

Claim 3 In line 4 of of Algorithm^ the order in which the agents are chosen does not matter. 

Proof (sketch). Follows from the fact that proofs are fixed on beforehand, as given by function Y>r : Q x LAC J {-L}, 
and do not depend on knowing whether other agents are being audited or not. (Intuitively, this models the fact that agents can 
not change their proofs on the fly, depending on whether other agents are being audited.) 

4 Formalization 

We have implemented the proof system and checking of the audit logic in Twelf 1131 . which is an implementation of the 
Edinburgh Logical Framework 1121 . Research in proof-carrying code 1101 has shown that Logical Framework (LF) provides 
a suitable notation for proofs to be sent and checked by a recipient. In type theories proof checking reduces to type checking 
and the LF proof checker is as simple as a programming language type checker (see also Sections- 
Here we only mention the most important features of the implementation. In the appendices we have included both a more 
abstract representation (common for a sequent calculus), as well as the complete Twelf-file. 

Audit Logic Implementation We first declare the types of the object logic, the atomic predicates and the actions. Then we 
present the proof rules and we finish with an example of a complete proof. 

Types In Twelf, a metalogic type is of type type. For object logic types, we use the type tp. The meta-logic function -> 
goes from type to type or kind (type has type kind). Agents, data, actions and policies are declared as tps. Finally, 
when declaring the rules for the object logic the tm type constructor is used, which casts arguments from tp to type. 
Summarizing: 

tp : type. agent: tp . policy: tp . 

tm: tp -> type. data: tp . action: tp . 

Policies Recall that policies are formed with says and owns and for example scenario-specific atomic predicates like 
print: 

says: tm agent -> tm policy -> tm agent -> tm policy, 
owns: tm agent -> tm data -> tm policy, 
print: tm agent -> tm data -> tm policy. 
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For instance, (print a d) is a policy stating that agent a has permission to print document d. Policies can also be 
formed using the usual propositional connectives and universal quantification^ (except for negation and disjunction); to model 
the different instances of implication in the policy language (see definition [0, we declare separate instances for use-once- 
obligations and use-many-obligations: 

imp: tm policy -> tm policy -> tm policy, 
forall: (tm T -> tm policy) -> tm policy, 
and: tm policy -> tm policy -> tm policy. 
?imp: tm action -> tm policy -> tm policy, 
limp: tm action -> tm policy -> tm policy. 

Below we assume that the connectives imp, and, ?imp, ! imp are declared as infix-operators. 

Actions The actions creates and comm have the following types: 

creates: tm agent -> tm data -> tm action. 

comm: tm agent -> tm agent -> tm policy -> tm action. 

The conclusion derivation function describes the policies the agent can deduce from some action. 

concl : tm action -> tm agent -> tm policy -> type. 
concl_comm: concl (comm A B Phi) B (says A Phi B) . 
concl_creates : concl (creates A D) A (owns A D) . 

In Twelf, symbols with a leading capital are variables. Their type can often be left unspecified, as Twelf expands them to the 
most general type. 

Proof derivation To model local proofs (with respect to agents), we use sequent calculus formulas of the form F; A \-a 3", 
indicating that agent A can deduce the policy $ from premises F and A. Here F is an unrestricted context and A a linear 
context. More precisely, F is a sequent of policies, actions and ?obligations, while A contains only !obligations. We formalize 
this with 

entail: tm agent -> list nonlin -> list lin -> tm policy -> type. 

where list T is the type for lists of type T. The type nonlin is like a disjoint union (policy, action, action) by the 
following definitions: 

nonlin: tp . 
lin: tp . 

act_c : tm action -> tm nonlin. 
?act_c: tm action -> tm nonlin. 
pol_c : tm policy -> tm nonlin. 
!act_c: tm policy -> tm lin. 

Rules The rules SAY and REFINE are defined as follows: 

say: entail B (cons (pol_c Phi) Gamma) Delta Psi -> 

entail B (cons (pol_c (says A Phi B) ) Gamma) Delta Psi. 

The OBS_ACT rule works as follows. If an agent A can conclude the policy $ by observing action act, then she can deduce $ 
from any set F containing act. In formula F, act; A $, in Twelf: 

obs_act : concl Act A Phi -> 

entail A (cons (act_c Act) Gamma) Delta Phi. 

The REFINE rule implements the possibility of refining a policy, cj) to tp and saying i/j, if one has permission to say ip. 
Refinement in this sense is expressed using empty sequents: 

refine: entail A (cons (pol_c Phi) nil) nil Psi -> 

entail A (cons (pol_c (says A Phi B) ) Gamma) Delta (says A Psi B) . 

^^Quantification over policies is not allowed, so we only instantiate the V-left and -right rales for the types agent and data. 
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The meaning of the DER_POL rule is that any formula can be derived, as long as, for all data affected by it, ownership is 
proven. To this end we define a relation on a non-linear sequent F and a policy (f>, op[r; (f>], that only holds iff all data affected 
by 4>, occur in some owns-predicate in T. 

op: list nonlin -> tm policy -> type. 

op_imp : (op Gamma Phi) -> (op Gamma (Psi imp Phi)) . 

op_f orall : ({X: tm data} op Gamma (Phi X)) -> (op Gamma (forall Phi)). 
op_says : (op Gamma Phi) -> (op Gamma (says B Phi C) ) . 
op_owns : (op (cons (pol_c (owns A D) ) Gamma) (owns B D) ) . 
op_print : (op (cons (pol_c (owns A D)) Gamma) (print B D)) . 

Now the DER_POL rule is defined as follows: 

der_pol : (op Gamma Phi) -> 

entail A Gamma Delta Phi. 

Please note that the structural rules and the logical rules for conjunction, implication and universal quantification over agents 
and data are omitted here, but they can be found in the appendices. 

Example 4 (Formalization of Example O Recall that Alice creates a document d(a review of a product) and communicates a policy, 
to Bob, that gives Bob permission to print d 'as soon as a related object exists'. Below Alice justifies that she can do so. First we declare 
the scenario-specific objects and predicates. 

a: tm agent, b: tm agent, d: tm data, 
rel : tm data -> tm data -> tm policy. 

phi = forall [x:tm data] ( (rel d x) imp (print b d) ) . 

ex2 : entail a (cons (act_c (creates a d) ) nil) nil (says a phi b)= 
obs_act concl_creates 
(cut 

(der_pol (op_says op_print)) 
(refine 

( f orall_r_data [x] (imp_r (w_l init)))) 
append_nil2 append_nil) . 

This theorem has been checked by Twelf. The proof goes along the same lines as previously in TableQ] 

The Ihs can be expressed as 7; (5 ha (a says to h), where cf) is Vx. rel(d, x) print(b,d) and 7 only contains the 
creates action, while 5 is empty. In the proof above, imp_r is the imp-right rule, forall_r_data is the y— right rule 
for quantification over data, w_l and init are weakening-left and the initial sequent axiom for the non-linear sequent. 

5 Related Work 

There is a wide body of literature on logics in Access Control (see the survey by Abadi Q). Here, we mention some 
of the proposals. Binder Q is a logic-based security language based on Datalog Binder includes a special predicate, says, 
used to quote other agents. Binder's says differs in two aspects from our construct: First, ours includes a target agent (see 
Section lZ4l : Second, when importing (i.e. communicating a policy in our setting) a clause in Binder, care must be taken to 
avoid nested says, since it may introduce difficulties in their setting. More related to our auditing by means of proofs, Appel 
and Felten j2l propose the Proof-Carrying Authentication framework (PCA), also implemented in Twelf (see Section 
Differently from our work, PCA's language is based on a higher order logic that allows quantification over predicates. Also, 
their system is implemented as an access control system for web servers, while in our case we focus on a-posteriori auditing. 

BLF 1191 is an implementation of a Proof-Carrying-Code framework that uses both Binder and Twelf, which however 
focuses on checking semantic code properties of programs. 

Sandhu and Samarati 1161 give an account of access control models and their applications. Bertino et al. propose a 
framework for reasoning on access control models, in which authorization rules treat the core components Subjects, Objects 
and Privileges. Sandhu and Park II II take a different approach with their UCON-model, in which the decision is modelled as 
a reference monitor that checks the 3 components: ACL, Conditions and Obligations. This reflects much the separation also 
made by us. Obligations and conditions are also prominent in directives on privacy and terms of use in DRM. The concept of 
purpose of an action is not used by us, but is used in the privacy languages P3P and E-P3P Unlike our policy language, 
E-P3P allows the use of negation, which requires special care to avoid problems in a distributed setting. 
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6 Conclusions and Future Work 



We have presented a flexible usage policy framework which enables expressing and reasoning about policies and user 
accountability. Enforcement of policies is difficult (if not impossible) in the highly distributed setting we are considering. 
Instead, we propose an auditing system with best-effort checking by an authority depending on the power of the authority to 
observe actions. A notion of agent accountability is introduced to express the proof obligation of an agent being audited. 

Our obligations cover pre- and post-obligations ( 1151 ') but not yet ongoing obligations. The setup does, with an adaption 
of the definitions of accountability, seem to provide the means to include this type of obligations. Obligations are 'use once', 
e.g. !pay($10) or 'use as often as wanted' ?pay($10). 

Our proof system has been implemented using the proof checker Twelf. The agents develop proofs using this implemen- 
tation. Likewise, the implementation allows an authority to check the agents' proofs. 

In our system, we include a powerful rule which allows delegating any policy to any other agent. Agent Alice may 
only want to use a policy from Bob if she (i) knows Bob, (ii) authenticates Bob, and (iii) trusts Bob. All these issues are 
(intentionally) abstracted away in our approach, as they seem to be orthogonal to our aims. For example, in (iii), the required 
level of trust may depend on the policy provided by Bob or on the way Alice is going to use the policy. There, a distributed 
trust management system (e.g. ^) could be employed to obtain the required level of trust. 

In the work of Samarati et.al. 1141 . a discussion about decentralized administration is presented. Specially, the revocation 
of authorizations is addressed. This is acomplex problem, which occurs as a consequence of the delegation of privileges. 
One could model revocation of policies by adding a special flag plus a corresponding check in a policy. However, checking 
whether a flag is set in another agent's environment is not realistic in our highly distributed setting. Further research is needed 
to find a both practical and realistic way to include rights revocation. 

Our implementation only covers proof checking. Revisiting FigureQ] we find that arrows covering policy communications 
and logging are not yet implemented. Our framework requires several properties for each of the different modules (e.g. secure 
logging and non-repudiable communications). Certainly, these properties need cryptography to be realized securely. We 
regard as future work the rigorous cryptographic definition of these properties, along with the accompanying cryptographic 
constructions. 

Acknowledgements The research presented in this paper is conducted within the PAW project (funded by Senter-lOP and 
TNO), the Inspired Project and the NWO Account Project. 
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A The Sequent calculus for the Audit Logic 

In Twelf we implemented a double context sequent calculus. To explain the Twelf-code more clearly, we start by giv- 
ing the (for sequent calculi) common representation of our system. In the formalization of our model we have in gen- 
eral (context); (hnear context) \-a policy , where A is the agent doing the reasoning, but below we can write shortly 
F; A h (f) (because rules regard only one agent-context). The contexts are sequents of linear and nonlinear propositions 
that serve as premises for the conclusion (right of the h sign). Now, in the Twelf code we declare 6 types of objects: agent, 
data, action, policy, nonlin, lin and a type list. In the sequel Greek and Roman letters denote variables that range over them. 
The type of the variables is often left implicit, so to distinguish the different types we use; A, B, C to denote agents, r, r' 
for lists of type nonlin. A, A' for lists of type lin, 70 and So for the empty lists of type lin and nonlin. Policies are denoted 
with (p, 0', t/' and ^' denote actions. To express append and construct operators for lists we just write a comma. And 
finally — >, A, V denote the policy connectives for implication, conjunction and universal quantification. We use ?imp and 
limp for the implication operators on obligations. Finally, in the non-linear context, we mix policy formulas (introduced by 
the standard logical rules), with actions (introduced by obs_act) and use-many-obligations (introduced with ?imp ). In Twelf 
each of these is mapped to the type nonlin. This context is thus like a list of the disjoint union of policy, action and action. 
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Below we only mention the main inference rules. For the type declarations and the definitions of lists and so on we refer 
to the Twelf code in the appendix. 

First our pivotal rules. Here we mention the A in because the agent appears explicitly in the formulas. 

SAY ^' ^ 



DBS_ACT 



REFINE - 



r,says(B,0,A);A hi V' 
r,co«c/(^,A); A h ip 



7o,0;^o K 



DER_POL 



r, says(A, 0, B); A Ka says(A, ip, B) 

op[r;V'] 



r;AhA V 



Note the apparent difference with for instance the SAY -rule in natural deduction style in Section|^3 It seems to have been 
turned upside-down; this is done to both keep the sub-formula-property, and preserve the redundancy of the cut-rule"*. 
The OBS_ACT-rule uses the conclusion derivation function, which is defined as: 

concl_creates : concl{creates{A, D), A) = ovins{A, D). 
concl_comm : concl{comm(A, B, 0), B) ~ says(A, (f), B). 

A few words on the REFINE-rule: The intention of the empty sequents is to prevent that an agent uses a fact to derive 
(j> ~^ for an otherwise unrelated (p. In formulas; T , tp h {(j) ^ ip) holds for any F and (/>. Then with just the permission to 
say (f), the agent can say ip, which is of course not the meaning of refining the policy (j>. This subtlety is not easily expressed 
in natural deduction rules, but in the sequent calculus this is done straightforwardly with the empty sequent 70. With this 
restriction in place only syntactically related policies can be used, for example for ip = ^ (j>) 01 tfj = While, if 
there exists such a relation for two (syntactically unrelated) predicates, then it should be expressed by adding a rule for it: 
7o,write(^, Z?) h read{A,D). 

Finally, the DER_POL-rule expresses that if a policy sets permissions on data Di, £)„ and each of the Di, Dn is 
owned by A then A can derive that poUcy. The notion of dataset of a policy in the article, is thus formalized a bit stronger 
here with the notion of active dataset, being the data that is actually affected by the policy. To this end we defined a relation 
on F and 4>: op[r; 0] that holds iff all data affected by <f), occur in some owns-predicate in F. The following rules make up its 
definition: 

op[r; 0] 

op_imp 



op_says 



op[r; (V- ^ <^)] 

[r;0(y 

3[r;V,^ 
op[r;( 



op[r;0(X)]^ 
op_f orall — ——^ (X a fresh constant) 

op[r;V(?!)] 



op[r;says(B,(/.,C)] 



Op.OWnS ; -r 

op[r, owns(A, D); owns(B, D)] 

op_pr int — p ; 7 : — ; -7 

op[r, owns(A, D); print(B, D)] 



A full proof of cut-admissibility and other meta-theorems ai'e future work 
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Where the last one is to show a scenario-specific predicate. Now we present the standard rules for the sequent calculus: 



iiiit ] ; — 

r,<^: A h 

r; A h r',(/!);A' h -tp 

cut 

r,r';A,A' hi V 

r>;Ah (j)' 

r,(0A^);Ah 0' 
r, V';A h 0' 

r; A h r'; A' h V 
r,r';A,A' h (0 A V) 

r;A h (/) r',0';A' h V 

r,r',(0^<^');A,A'h v 
r, (?!>; A h V 



and_ll- 



and_12 



and_r- 



imp_l ■ 



imp_r- 



r;Ah 



We need similar left and right rules for the limp and ?imp operators. Recall that use-many obligations go into the unre- 
stricted context, while use-once obligations go into the linear context. Here are the two pairs: 

r;Ah (e limp 4,) 

!imp_l- 



limpjr- 



?imp_l 



r;A,eh 
r;Ah 



?imp_r- 



r;Ah (e!imp0) 

r;Ah (g?imp0) 
r,e;Ah </) 

r:Ah 



r;Ah (e?imp0) 

In Twelf we coded twice the following V -left and V -right rules; one for agents, one for data. But not for actions or policies. 

r,0(X);Ah ^ 



f orall_l- 



^,V0; A h V 



f orall_r X a fresh constant 

r;Ah V<?!) ^ ^ 

Finally, we have the structural rules for the unrestricted and the linear contexts. The linear context doesn't allow for 
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contraction. 

r; A h 

w_l- 



r; A h 



w_l_act- 



contr_l 



perm_l 



r;A,Ch 

(r,(/)),0;Ah V; 
r,0;Ah 

r, r'; Ah V 



r,(/.',0,r';Al- V 
r;A,e,C',A'h < 



perm_act- . , , 

r;A,e',e,A'h 

Which wraps up the list of rules. We now show some examples of proofs in this notation. 
A.l Example: Creating and consuming a policy 

Let's draw the proof-tree of example 2a in this notation. We use abbreviations in this example: 

(j) = \/lP 'ip{x) = {'ipi{x) ^ 1P2) 
^pi{x) = re\{d, x) -02 = pi'int(5, d) 
7 = 7o,owns(a, d) 7' = 70, -^^(d') 

In words: Agent a proves that she can say policy 4> to agent b. 

op.print 

op[7;'02] 

op.says- 



op[7;says(a, V2,&)] 70 , V'2 ; (5o l- 

DER_POL REFINE - 



7;Jo^ says(a, V'2,fe) 70, says(a, -02, &); (5o h says(a, 0, fe) 



cut - 



7; So h says(a, cp, h) 

□BS JICT 



70, creates{a, d);6o h says(a, 0, b) 

Please note that the use of both the REFINE and the DER_POL-rule, and thus the cut-rule, is only done to stay close to the 
natural deduction style proof given earlier in the article (see Table In fact, by using only the DER_POL-rule one could 
derive the same permission. The premise of the REFINE-rule is easily proven: 



init 

7O,02;OO I" 02 
W.1 

7O,02,0l(2/);(5o h ■02 
imp_r 

7o,02;(5o I- (01 (y) 02) 

f orall_r 

70, 02; do I- V0 

Now agent 6, who receives the mentioned policy, proves that he has the permission to print - using the evidence of the 
communication by a and the assertion on d' (inside 7') which is asserted by 5's environment. 



init - 



Y]5o\- 0i(d') 7o,'02;<5ol- 02 

imp_l 

7',(0i(d')^02);'5oh 02 

f orall.1 

7', V0; So h 02 

SAY 

7',says(a, 0, 6);(5o h i/'2 

DBS JICT 



7', comm{a, b, 0) ; (5o 1^ ^2 
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A.2 Example: Fulfilling use-once obligations 



Finally let's see a policy with !imp in it. The drink-beer example is fine. Suppose the bartender, a, has communicated 
the poUcy to a customer, b. The customer has to prove po{drunk{b, beer)) = drink{b, beer). The abbreviations are: 

(p^y-ip -0(a;) = (V'l (a;) !imp '02(x)) 

i^iix) —paid{x,5$) '>p2{x) ~ drink(a;, beer) 

^ = comm{a^ b, (p) ^' = paidib, 5$) 

Now agent b uses the evidence of the communication and the obligation paid{b, 5$) to prove that he is allowed to drink one 
beer having paid 5$. 

init 

jo,i^ib);So \- (Mb) !imp?A2(b)) 

!imp_l 



7oX&);^o,e'^ Mb) 

f orall.1 

7o,VV';^o,?' I- 4'2{b) 

SAY 

7o,says(a,V-0,6);5o,?' I" Mb) 

OBS.ACT 

7o,?;<5o,e^ Mb) 

B TwelfCode 



%% Object logic types 

tp : type. 

tm: tp -> type. 



%% Objects in the Audit logic 
agent : tp . 
data: tp . 
policy: tp. 
action: tp. 



%% Atomic Predicates 

says: tm agent -> tm policy -> tm agent -> tm policy, 
owns: tm agent -> tm data -> tm policy. 
%% — application-specific atomic predicates go here 
print: tm agent -> tm data -> tm policy. 



%% Policy grammar (with infix-operators for sugared writing) 
imp: tm policy -> tm policy -> tm policy. %infix right 11 imp. 
forall: (tm T -> tm policy) -> tm policy. 

and: tm policy -> tm policy -> tm policy. %infix right 12 and. 

%% — note: only quantification over agents and data have introduction rules 

%% Obligation implications for use-once ! imp and use-many ?imp 
?imp: tm action -> tm policy -> tm policy. %infix right 11 ?imp. 
limp: tm action -> tm policy -> tm policy. %infix right 11 limp. 



%% Core actions comm and creates 

comm: tm agent -> tm agent -> tm policy -> tm action, 
creates: tm agent -> tm data -> tm action. 
%% — application-specific actions can go here 
printed: tm agent -> tm data -> tm action. 

%% Conclusion derivation function 

concl : tm action -> tm agent -> tm policy -> type. 
%% Core concl relations 
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conol_comm: concl (comm A B Phi) B (says A Phi B) . 
concl_creates : concl (creates A Data) A (owns A Data) . 



%% Just 3 more objects: list, lin and nonlin 

list: tp -> type. %%sequents are lists of lin and nonlin 

nil: list X. 

cons: tm X -> list X -> list X. 
in: tm X -> list X -> type. 
in_cons_head : in X (cons X Lx) . 
in_cons_tail : in X (cons Y Ly) <- in X Ly . 
append: list X -> list X -> list X -> type. 
append_nil : append nil X X. 
append_nil2 : append X nil X. 

append_cons : (append (cons X XS) YS (cons X ZS) ) <- (append XS YS ZS) . 

nonlin: tp. %% nonlinear for the unrestricted sequent Gamma 
lin: tp. %% linear for the linear sequent Delta 

pol_c: tm policy -> tm nonlin. %% three types go into the nonlinear sequent 
act_c: tm action -> tm nonlin. 
?act_c: tm action -> tm nonlin. 

! act_c : tm action -> tm lin. %% only actions in the linear sequent 

%% The Entailment for the double context sequent calculus 

entail: tm agent -> list nonlin -> list lin -> tm policy -> type. 

%% — (entail A Gamma Delta Phi) is in latex: \Gamma; \Delta \vdash_A \Phi 



%% The 4 Audit logic "pivotal" rules 

%% - - SAY 

say: entail B (cons (pol_c Phi) Gamma) Delta Psi -> 

entail B (cons (pol_c (says A Phi B) ) Gamma) Delta Psi. 

%% - - OBS_ACT 

obs_act : concl Act A Phi -> entail A (cons (pol_c Phi) Gamma) Delta Psi 
-> entail A (cons (act_o Act) Gamma) Delta Psi. 

%% - - REFINE 

refine: entail A (cons (pol_o Phi) nil) nil Psi -> 

entail A (cons (pol_c (says A Phi B) ) Gamma) Delta (says A Psi B) . 

%% - - DER_POL 

%% — a new relation, op, is needed for the der_pol rule 

op: list nonlin -> tm policy -> type. 

op_imp : (op Gamma Phi) -> (op Gamma (Psi imp Phi)) . 

op_forall: ({X: tm data} op Gamma (Phi X)) -> (op Gamma (forall Phi)). 

op_says : (op Gamma Phi) -> (op Gamma (says B Phi C) ) . 

op_owns : (op (cons (pol_c (owns A D) ) Gamma) (owns B D) ) . 

%% — application specific predicates go here 

op_print : (op (cons (pol_o (owns A D)) Gamma) (print B D)) . 



der_pol: (op Gamma Phi) -> 

entail A Gamma Delta Phi. 



%% Common Inference rules for the Sequent Calculus 
init : entail A (cons (pol_c Phi) Gamma) Delta Phi. 
cut : entail A Gamma Delta Phi -> 

entail A (cons (pol_c Phi) Sigma) Epsilon Chi -> 

append Gamma Sigma Pi -> 

append Delta Epsilon Rho -> 
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entail A Pi Rho Chi. 
imp_l : entail A Gamma Delta Phi -> 

entail A (cons (pol_c Chi) Sigma) Epsilon Psi -> 
append Gamma Sigma Pi -> 
append Delta Epsilon Rho -> 

entail A (cons (pol_c (Phi imp Chi)) Pi) Rho Psi. 
imp_r : entail A (cons (pol_c Phi) Gamma) Delta Chi -> 

entail A Gamma Delta (Phi imp Chi) . 
and_ll: entail A (cons (pol_c Phi) Gamma) Delta Chi -> 

entail A (cons (pol_c (Phi and Psi)) Gamma) Delta Chi. 
and_12 : entail A (cons (pol_c Psi) Gamma) Delta Chi -> 

entail A (cons (pol_o (Phi and Psi)) Gamma) Delta Chi. 
and_r : entail A Gamma Delta Phi -> 

entail A Sigma Epsilon Chi -> 
append Gamma Sigma Pi -> 
append Delta Epsilon Rho -> 

entail A Pi Rho (Phi and Chi) . 
said only instances for agents and data 

agent: {X:tm agent} entail A (cons (pol_c (Phi X)) Gamma) Delta Chi -> 

entail A (cons (pol_c (forall Phi)) Gamma) Delta Chi. 
agent: ({X:tm agent} entail A Gamma Delta (Phi X)) -> 

entail A Gamma Delta (forall Phi) . 
data: {X:tm data} entail A (cons (pol_c (Phi X)) Gamma) Delta Chi -> 

entail A (cons (pol_c (forall Phi)) Gamma) Delta Chi. 
data: ({X:tm data} entail A Gamma Delta (Phi X)) -> 
entail A Gamma Delta (forall Phi) . 
%% Obligation implications 

! imp_l : entail A Gamma Delta ( Act limp Psi) -> 

entail A Gamma (cons ( ! act_c Act) Delta) Psi. 
! imp_r : entail A Gamma (cons ( ! act_c Act) Delta) Psi -> 

entail A Gamma Delta (Act limp Psi) . 
?imp_l: entail A Gamma Delta (Act ?imp Psi) -> 

entail A (cons (?act_c Act) Gamma) Delta Psi. 
?imp_r: entail A (cons (?act_c Act) Gamma) Delta Psi -> 
entail A Gamma Delta (Act limp Psi) . 

%% Common Structural rules 

w_l : entail A Gamma Delta Phi -> 

entail A (cons Chi Gamma) Delta Phi. 
w_l_act : entail A Gamma Delta Phi -> 

entail A Gamma (cons Chi Delta) Phi. 
contr_l: entail A (cons Phi (cons Phi Gamma)) Delta Chi -> 

entail A (cons Phi Gamma) Delta Chi. 
perm_l : entail A Pi Delta Psi -> 

append Sigma (cons Phi (cons Chi Gamma)) Pi -> 
append Sigma (cons Chi (cons Phi Gamma)) Rho -> 
entail A Rho Delta Psi. 
perm_act : entail A Gamma Delta Psi -> 

append Sigma (cons Actl (cons Act2 Tau) ) Delta -> 
append Sigma (cons Act2 (cons Actl Tau)) Epsilon -> 
entail A Gamma Epsilon Psi. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%% Formalization of example 2 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
a : tm agent . 
b : tm agent . 
d: tm data. 
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rel : tm data -> tm data -> tm policy. 

phi = forall [x:tm data] ( (rel d x) imp (print b d) ) . 

ex2:entail a (cons (act_c (creates a d) ) nil) nil (says a phi b)= 
obs_act concl_creates 
( cut 

(der_pol (op_says op_print) ) 
(refine 

( f orall_r_data [x] (iinp_r (w_l init)))) 
append_nil2 append_nil) . 

%% same account without the cut-rule 

ex2b:entail a (cons (act_c (creates a d) ) nil) nil (says a phi b)= 
obs_act concl_creates 

(der_pol (op_says (op_forall [x] (op_imp op_print) ) ) ) . 
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